home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
081
/
matrix.arc
/
MATRIX.DOC
next >
Wrap
Text File
|
1987-05-11
|
55KB
|
1,456 lines
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░ ░░░░░░░ ░░░ ░░░ ░░░ ░░░░ ░░ ░░░░░░ ░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓░░ ▓▓▓▓▓▓▓░░░ ▓▓▓▓▓▓░ ▓▓▓▓░░░░░ ▓▓▓▓░░░░░░
░░░░ ▓▓▓░░░░ ▓▓▓░░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓▓▓░░░▓▓▓▓▓▓░░ ▓▓░░░░░░░ ▓▓░░░░░░░
░░░░ ▓▓▓▓░░ ▓▓▓▓░░ ▓▓░░░ ▓▓░░▓░ ▓▓░░▓░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░ ▓▓░░░░░ ▓▓░░░░░░░░
░░░░ ▓▓░▓▓ ▓▓ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░ ▓▓░░░ ▓▓░░░░░░░░░
░░░░ ▓▓░░░▓░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░░ ▓▓ ▓▓░░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓ ▓▓░░░░ ▓▓░░░░ ▓▓ ▓▓░░░░ ▓▓░░░░░░░░ ▓▓▓▓░░░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░░░░ ▓▓░░░░ ▓▓▓▓▓▓▓░░░░░ ▓▓░░░░░░░░░ ▓▓░░░░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░░░░ ▓▓░░░░ ▓▓▓▓▓▓░░░░░░ ▓▓░░░░░░░░ ▓▓▓▓░░░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░ ▓▓░░░░░ ▓▓░░░░░░░ ▓▓░ ▓▓░░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░ ▓▓░░░ ▓▓░░░░░░░░░
░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░ ▓▓ ░░░░ ▓▓░░░░░ ▓▓░░░░░░░░
░░░ ▓▓░░░░░ ▓▓░ ▓▓░░ ▓▓░░░ ▓▓░░░ ▓▓░░░ ▓▓░░ ▓▓▓▓▓▓░ ▓▓░░░░░░░ ▓▓░░░░░░░
░░░░▓▓▓▓░░░░░▓▓▓▓░▓▓▓▓░░▓▓▓▓░░░▓▓▓▓░░░▓▓▓▓░░░▓▓▓░░▓▓▓▓▓▓░░▓▓▓░░░░░░░░▓▓▓░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
+---------------------------------------------+
| |
| "Arrogance is the mother of invention." |
| |
| - Guido Palermo - |
| Opus Bylaws and Covert Action Committee |
| |
| |
| |
| Actually, Guido just claims this |
| quote. When I checked, the quote's |
| serial number had been filed off... |
| so it's impossible to tell for sure. |
| |
+---------------------------------------------+
+-----------------------------------------------------------+
| |
| The Opus Computer-Based Conversation System |
| (c) Copyright 1987, Wynn Wagner III, All Rights Reserved |
| |
| YOOHOO and YOOHOO/2U2 are |
| Copyright 1987, Wynn Wagner III, All Rights Reserved |
| |
+-----------------------------------------------------------+
WHAT YOU ARE READING
--------------------
Because of a great deal of interest in Opus outbound, we're
releasing this document before the release of the code.
This file explains the theory behind Opus outbound in a
general sort of way.
The document is preliminary. Everything here is
subject to change.
------------------------------------------------------------------------------
Opus now supports outbound matrix messages.
This file is a general explanation of the methods involved
with sending messages from your system to other systems.
IMPORTANT
---------
You won't find any step-by-step information here. This is
a discussion on the theories behind Opus Outbound.
The reason is that the ideas are going to seem a little
different. I'll go further and say that if you skip this
background information, you are going to have a hard go of
it later!
I feel it's important to setup your head for all of this
before you setup your computer.
SIMPLE
------
Doing outbound mail with Opus is fairly simple. In fact,
getting that message across has been one of the toughest
jobs.
Some of the beta testers say most of their work fell into
one of two categories:
* deleting lines of batch and routing files
* convincing themselves that fewer lines of
instruction will do just as much work
IDEA #1
-------
With Opus, "mail events" are less important. To be
thoroughly honest about it, they don't even exist.
Instead, we'll be dealing with "behavior windows."
With an event, you have to give every detail... making
statements that are procedural in nature.
With a behavior window, you paint with a wide brush telling
the system what to do with classes of remote systems.
When systems could handle matrix traffic only during special
times, routing and times were important. Because more and
more systems can process mail at any time, the idea of a
schedule becomes less important.
The item of prime importance in Opus is COST. We are going
to try to relieve you of the tedius details of scheduling
and concentrate on doing things for the least cost.
There'll be more on this later.
IDEA #2
-------
Another new idea deals with the way bundles are created.
A "bundle" is what some other systems call a "packet." In
network operations, a packet has a special meaning... a meaning
that has nothing to do with network mail. An "XModem Block"
is a packet in network terminology. To avoid confusion with
an established word, Opus docs use "bundle."
Anyway... you are probably used to seeing bundles generated
several times. With some programs, bundles are build every
time a mail schedule starts. As a result, one message may be
put into a bundle several times.
With Opus, bundles are built once by an external program called
oMMM (the Opus Matrix Message Masher). Although I wrote the
original oMMM, Bob Hartman has adopted the program and has
added lots of widgets and handy features.
IDEA #3
-------
Opus uses "Continuous Mail". If you are already using a program
that supports "Crash Mail", then you understand a liitle of what
Continuous Mail does. Continuous Mail differs from Crash Mail in
a couple of areas.
In other mailer systems, you would mark a message a "Crash"
meaning that you wanted this message to go out NOW. These mailer
programs would shut down human caller access to the bbs and
try like the dickens to get that message through.
Opus uses Continuous Mail, meaning that this is a message going
to a system that can accept mail at any time of the day. Opus
does not make any frantic attempts to dial out, rather it will
try to deliver the mail in between human callers. The actual
routine to determine if Opus should call or not is based on the
number of seconds Opus has been free without either a human caller
or a previous mail attempt. It is a random number of seconds,
between 30 seconds and 2 minutes.
You can control this behavior with "Z-Event Windows" that we will
cover later.
IDEA #4
-------
The driving forces of outbound traffic are file names!
You'll have a special sub-directory set aside just for bundles
and other matrix files. It's a sub-directory that belongs to
Opus and shouldn't have anything else put in there. Opus will
maintain this sub-directory for you.
It's kind of a "black hole." David Finster says it takes
some getting used to.
As soon as you run oMMM, messages that are marked KILL/SENT
in your matrix message area will disappear. They haven't
been sent, yet. They're just bundled and ready to go.
File names are important to opus...
BUNDLE NAMES
------------
The file names of the bundles tell Opus how to treat the
different bundles. Here's a typical bundle name:
12345678.OUT
That says the bundle is for 1234/5678. The numbers are in
hex (base 16). The ".OUT" means it is a regular bundle.
Other bundle extensions include:
.HUT ... hold the bundle for pickup
.CUT ... the other system can receive
continuous mail
One nice thing is that you can manually change the file's
extension if you need to. That would change the behavior
of the bundle when Opus sees it next.
The oMMM program knows about these extensions and creates
them based on information you put into the oMMM control
file. You'll have statements like this:
HOLD 124/102
That would create a .HUT bundle file, and Opus will hold
that packet for 124/102 to call and pick it up.
FLOW FILE NAMES
---------------
Files are also sent through the matrix. oMMM builds and
maintains a file that tells Opus what files to send (or hold)
for whom. A typical "file attach" file might be named:
12345678.FLO
Other flow file extensions are:
.HLO ... hold these files for pickup
.CLO ... the other system can receive
continuous mail
A flow file is just a text file. It contains a list of files
that are to be sent to another system:
e:\net\outbound\00096581.mo1
e:\pascal\notes.doc
File names in a flow file never include wildcards.
ARCHIVED MESSAGES
-----------------
The oMMM program will put messages into archives for you.
Details on how this is done can be found in the oMMM
documentation.
The point here is that oMMM combines the functionality of
"generating packets" with that of programs like ArcMail.
oMMM creates archives using the same numbering convention
as other message archive programs. The file name is the
difference between the sender's net/node and the receiver's
net/node. The file extension is ".MO#" where `#' is a
number between 0 and 9. In this case, MO stands for "messages
for outbound" and has nothing to do with Monday. oMMM will
NOT produce a "TU" or "WE" (etc) file.
EXAMPLE
-------
So far, we've covered bundles and flow files. We've also hit
on some of the high points of oMMM.
Here's the flow of a message...
Let's say I've written a message to Mike Kelleher. The message
is in my matrix message area and is flagged KILL/SENT.
oMMM is executed to convert the message into a bundle. In my
control file for oMMM, I have this:
CRASH 161/521 161/ALL
The word "crash" is VERY misleading. We just haven't come up
with a better word, yet. CRASH in this case means that Mike
(161/521) runs a system that can receive continuous mail.
This control file line tells oMMM to build a message archive
to 161/521. In the archive will be any messages to Mike (521)
as well as messages to anybody else in net 161.
When the flurry of activity dies down, you'll have a file
called "00A10209.CLO" and another one with an ".MO1" extension.
The message is now in queue.
+-------------------------------+
| |
| "Roads? Where we're going we |
| don't need roads." |
| |
| - from Back To The Future |
| |
+-------------------------------+
ENTER OPUS, STAGE RIGHT
-----------------------
Opus can tell by looking at the outbound sub-directory (called
the HOLD AREA) that there's a bundle for Mike. Opus can tell
that Mike's system can receive continuous mail.
It's in the middle of the afternoon. Phone rates between Dallas
and San Francisco are the highest they'll be all day. It's a
bad time to call.
We aren't controlling calling times because of our software.
The software doesn't care. Both ends can handle matrix traffic
at any time. We're controlling calling times based on the
phone rates.
I have a Z-EVENT set in Opus that tells the system to make calls
only to local systems that can receive continuous mail.
Z-EVENT: The Behavior Window
----------------------------
A Z-EVENT is setup using the Opus event manager. It starts
out looking like any other event... except that it has a
Z for a tag.
In addition to the start time and event length, there are
several yes/no questions that go along with a Z-EVENT:
Local only? .......... YES: only make calls to systems
whose cost field is 0.
NO: it's okay to make calls
that cost money
#CM only? ............ YES: only call systems who have
.CUT and/or .CLO files
NO: not restricted to continuous
mail systems
Mail only? ........... YES: don't let human callers
on-line, concentrate on mail.
NO: humans and the matrix coexist.
File requests ok? .... YES: let other systems make file
requests
NO: don't allow file requests
During the day, I have a Z-EVENT that has LOCAL, #CM, and
FILE REQUESTS set to YES. I don't want to make long-distance
calls, and I don't want to call systems that can't handle
mail on a continuous basis.
POOR MIKE, JUST HANGING OUT
---------------------------
So, there sits the .CLO file for Mike (see EXAMPLE above).
Although it says Mike's board can accept mail on a continuous
basis, the COST field in the node list for 161/521 isn't zero.
It's a long distance call.
Opus will not call 161/521.
At midnight, the phone rates are lower. I have another Z-EVENT
that allows #CM only. In other words, at midnight I drop the
requirement that all calls be local.
At that point, Opus will start trying to send the stuff. (Knowing
Mike's board, it will take all night to get it through!)
Z-EVENT OVERVIEW
----------------
Here's how my Z-Events go...
Daytime ..... #CM, LOCAL
Overnight ... #CM
NMH ......... MAIL_ONLY
For NMH (National Mail Hour), I drop the #CM requirement.
That let's Opus send to systems that can't handle continuous
mail.
The point to all of this is that messages stay bundled all
the time. What changes is the behavior of Opus.
THAT'S ABOUT IT
---------------
At this point, the standard reaction is "I have some special
cases that this won't handle. I have several pages of routing
and batch files to do all this special stuff."
This is my experience: sysop thought patterns are what
complicate matters.
Possibly there are some special cases that Opus outbound can't
handle. I haven't seen any.
In the rest of this file, you'll find excerpts of NEW.DOCs form
various beta releases. There are details on the HOLD AREA (sub-
directory), file requests, and dialing scripts.
Control file additions
----------------------
Matrix Hold Area
----------------
Opus wants its own sub-directory for outbound traffic.
Declare that area like this:
MATRIX HOLD_AREA C:\Opus\Outbound\
The system will maintain that sub-directory for you. There
are no user-servicable parts inside.
That's not really true. We'll be storing the OUT, FLO, and
MO? files there. You can change the names of the files, and
that will affect the behavior of Opus.
I strongly suggest you don't put other files in this
holding area.
Outbound Matrix Traffic
-----------------------
You have two primary methods for controlling phone calls made
by your Opus system: the control file and the event manager.
The control file method is in effect if there is no event
to over-ride it. In other words, Opus will give priority to
the event (described later).
To disable outbound calls, put this into your control file:
Matrix Send NOTHING
To disable long distance outbound calls, put this into your
control file:
Matrix Send LOCAL
With those two restrictions, Opus now attempts to send any
outbound material it finds in the sub-directory declared
as your Hold_Area.
If you want to keep humans off-line during a critical mail
period, include this:
Matrix Allow MAIL ONLY
IMPORTANT: You can over-ride these control file settings
with the "Z" Behavior Windows described below.
More on "Z" Windows
-------------------
+----------------------------------------------+
| |
| "But what HAPPENS during this event?" |
| |
| "Nothing. It's not a real event. A better |
| phrase would be BEHAVIOR WINDOW." |
| |
+----------------------------------------------+
When a "Z" event is in progress, it's settings remain in
effect until the next "Z" event. In other words, the
settings do NOT RETURN TO THEIR ORIGINAL VALUE at the "end"
of this event.
Let's say you declare a "Z" event for every day of the week
from 9am to noon. The behavior you describe in the "Z" event
will be in effect for those three hours. Here's the part that
needs to be stressed... at noon, the behavior will remain in
effect unless there is a "Z" event declared then.
That should probably be repeated...
* You can setup matrix behavior in the control file.
If Opus runs into a "Z" event that is in progress,
those control file values are gone for the life
of the program.
* To actually "end" a "Z" event, you have to begin
another "Z" event. In this case, the duration of
the event means "go to these values whenever you
find yourself in this time period."
* The end of a "Z" event does NOT mean return to the
old values.
* Whew.
NOTE: All of this does not mean that you can take the lazy way out
and set your Z windows for a duration of 1 minute. You should
still set the duration for the actual lenght of the window so
that Opus will know what to do when you start the program in
the middle of a window.
You can use this event to set the following items:
Local only.........No "Cost" phone calls are made
Regular mail.......Outbound goes to all (except HOLDs)
Continuous mail....Only packets (etc) marked for
continuous mail are sent
Mail only..........No human callers are allowed on-line
No traffic.........Outbound mail is turned off
Using the "!" command off the main menu, select the event
section. Then just set an otherwise unused event to a type "Z".
Additional selections will appear.
Matrix Bundling
---------------
There is no internal bundler (the thing that maintains
message bundles destined for some other system). You can
exit Opus with a pre-set ErrorLevel to call the bundler
program when the contents of the matrix area changes.
For example, if you call and enter a message into your
network area, Opus will exit with an ErrorLevel of 11
*after* you have ended your regular session...
Matrix After Edit Exit 11
For information on one possible bundling method, refer to
"oMMM"... a stand-alone no-frills bundling program.
Enabling File Requests
----------------------
If you want to allow file requests, put this into your control
file:
Matrix allow requests
IMPORTANT: You can temporaraly over-ride these control file
settings with the "Z" windows described earlier.
Approval Listing
----------------
In addition, you will need a file containing a list of files
approved for file requests. This is a standard, garden-variety
text file. It MAY include wildcards. Declare the file like this:
Matrix okfile c:\opus\okfile.lst
This is a "raw" list. It should contain nothing other than
file name. Only one file name should be on a line. The items
must begin in the far left column.
Example: c:\dl\pascal\*.*
c:\net\node*.a??
c:\dl\forth\this.one
^
|
|
Pretend this starts way over there
|
<---------------------------------------------------------+
SYSTEM ADVERTISEMENT AND FILE LIST
----------------------------------
One more declaration will generalize your list of available
files. In other words, if somebody wants to know what you have
on-line that is available for requesting, the standard Opus
method is to request a file called FILES. When Opus receives
a request for FILES, it will automatically transmit the
file you declare like this:
Matrix avail c:\opus\filelist.arc
NOTE: Do NOT put comments on the `okfile' or on the `avail'
lines.
In addition to a listing of files, it would be a good idea
to include a statement that wildcards are not allowed on
file requests (see below). This file can also tell the
caller something about your system.
You include the extension in the control file... so the file
can be a TXT, DOC, ARC or any other kind of file.
PLEASE do not use "filelist.arc" as the name of the file.
For The POLE, we're using "POLELIST.LST". Using this scheme,
every system can have a unique file name. This should make
file management much easier on the caller.
IMPLEMENTATION RESTRICTION
--------------------------
The requesting system cannot use a wildcard in the file
name. By letting you put wildcards in the list of approved
files, it makes it a little tedious to allow wildcards in
the request. Not impossible. Just tedious. So... to make
things easy on the sysop... I made a design decision to make
it harder on the calling system. This will probably change
sometime down the line, but I have my hands too full to worry
about such stinkin' nicities. As it were.
ERRORS: NO SUCH FILE
--------------------
This version of Opus sends the "avail" file if no requested
files are available. Eventually this Oops file will be
separate and configurable via the control file.
BEFORE ANYBODY ASKS
-------------------
No, Opus does not currently have a method for initiating
file requests.
Opus can only accept a file request from another system.
SPECIAL MATRIX MENU
-------------------
When Opus is waiting for a call, you can get to a special
matrix section.
Press "M" when you see the "Ready" status line.
The menu includes these items:
INFORMATION............generate a chart showing the status of
pending outbound traffic.
POLL...................call a system whether or not there is any
pending outbound mail. If there is a
connection, Opus will dynamically generate
and transmit a dummy message bundle if there
isn't a real one available.
As many as 9 or 10 tries will be made. You
can stop the poll by pressing <esc>. If no
connection is made after several attempts,
Opus will recycle to its on-line ("Ready")
state.
If a connection is made, you can expect any
items to be transmitted ... even those
marked as "hold".
When you cancel a poll, you may have to
press <esc> a couple of times. The first
will cancel the current call. The second
one will cancel the polling sequence.
UNPACK.................process/toss any PKT files found in the
current default sub-directory. This is the
same thing as the familiar `-u' command
line option.
CLEAR UNDIALABLES......Delete all "*.$$#" marker files in the
outbound area. Opus keeps these files to
mark which boards have been called
unsuccesfully. If these files are not
deleted, Opus will never try them again.
They can also be deleted automatically,
using a "Z" maintance event.
UNSUCCESSFUL CONNECTIONS
------------------------
Previous versions would make an undetermined number of phone
calls to a remote system.
Beginning with this version, a counter is maintained. It is
incremented when there is a connection that does is not
consumated. If there is a carrier but no matrix session,
this counter gets bumped.
TECHIE STUFF MOST CAN SKIP
--------------------------
The counter is a 0-byte file in the outbound holding area.
The file name is something like this:
########.$$#
|||||||| |
\||/\||/ |
\/ \/ |
net node counter
The net and node are 4 character hex numbers. The counter can
be anything from 0 to 9.
If Opus finds such a file, it's supposed to refuse to make a
call if the counter is 4 or greater. If it equals 4, you'll
get a log entry.
The "flag" for this counter is an "?" in the middle of the
extension. The first character of the extension is also an
"$"... but that is NOT guaranteed for future versions. You
should use a wildcard for the first character if you want to
be upward compatible.
Sneaky Arrogant Hacker Trick: if you want to guarantee continued
calls, try building a read-only file that looks like the counter
file. It should have a low counter value. If the file is
read-only, Opus will see it but will be unable to increment the
counter. I should say this is totally untested, but it sounds
like it might work.
The reason for such a method is simple. A 0-byte file takes up
NO disk space except for the directory entry. Plus, it is easy
to access because DOS does a good job of buffering directories.
Access routines are in DOS ... so they don't have to be in Opus.
In other words, it seems like a good way to us "database code"
that's already in your computer... and to do so without using
up any disk space you don't already have allocated.
PLEASE READ THIS PART
---------------------
Here's the situation... if Opus finds the counter file showing
it tried to call a board unsuccessfully... it will not make
further calls.
You can manually delete them to enable further calls to
the board(s) in question by using the "Clear Undialables"
command on the Matrix Menu.
There is also a HOUSECLEANING Z-EVENT which will remove these
Dollar-Sign Files.
IMMEDIATE CALL
--------------
When Opus is waiting for a call, you can force it to make an
outbound call immediately.
Press "C" when you see the "Ready" status message.
If it feels it needs to, Opus will make a call. In other words,
this does not force Opus to actually originate a matrix session
unless there is sendable outbound traffic.
WILD ECHOMAIL
-------------
The unarc routine now uses wildcards. In other words, it will
try to unarc "*.MO?" in your matrix hold area.
If you get something from a message archiver other than oMMM
(ie "TU?", "WE?"....), it will try to unarc that specific file.
This change means that attached messages are no longer needed
for archived messages! oMMM does not produce such a message.
NEW MATRIX BEHAVIOR MASK
------------------------
Using the event setup menu, you can tell Opus not to
exit after Crash Mail and ArcMail.
The mask is called "Exits suppressed" on the menu.
If you turn this on, then any "EXIT AFTER CRASHMAIL" and
"EXIT AFTER ARCMAIL" in your control file are ignored.
------------------------------------------------------------------------------
MATRIX SESSION SCRIPTS
----------------------
+-------------------------------------------------------+
| |
| "This is where the D.J. talks, Don't say anything." |
| "O.k., eh." |
| ---- Bob and Doug McKenzie |
| |
+-------------------------------------------------------+
Instead of a phone number, the "phone" field of a record in
the node list can contain the name of a script file.
Script files are in quotes...
PHONE NUMBER: 555-1212
SCRIPT FILES: "555-1212"
"HARDWIRE.CTL"
"SATORE.SPT"
All script files must be in the sub-directory you've declared
as being the NET_INFO sub-directory.
NOTE: This addition to Opus does not address any methods for
getting a quoted file name into the node list. But if
you can get them in, Opus will understand them.
CONTENTS OF A SCRIPT FILE
-------------------------
A script file is created with a text editor. Each line must
contain a KEYWORD. In most cases, it will contain other material.
The keyword must be in the far lefthand column of each line. The
system is not sensitive to the case of keywords... upper- and
lowercase is the same.
Some keywords require additional information. You should put
a single space after the keyword, then start typing the
additional information. In other words, if you put a keyword
then TWO spaces... the second space will be considered part of
the additional information.
KEYWORDS
--------
In the examples below, please pretend the keywords appear in the
far lefthand column!
-----------------------------------------------
XMIT ... send something to the modem. As in the
modem initialization string in the control
file, Opus understands the following
special characters:
~ ... slight pause
| ... transmit a <cr> character
EXAMPLE:
xmit ATZ|
xmit AT|~ATHO|
-----------------------------------------------
DIAL ... transmit whatever additional information
appears on the same line of the script,
then wait for a modem response.
If the modem reports any kind of failure
(eg "BUSY"), the script will be terminated.
NOTE: The dial "prefix" and "suffix" from
the control file are NOT used here.
EXAMPLE:
dial 555-1212
-----------------------------------------------
PHONE ... a special-case way of transmitting the remote
system's phone number. It works like XMIT.
In other words, there's no waiting around
for a response.
-----------------------------------------------
WAIT ... wait for a character from the remote system.
A 40 second period of no input will terminate
the script.
EXAMPLE:
wait :
wait =
-----------------------------------------------
SESSION ... in most cases, this will be the last keyword
in your scripts. It means Opus should begin
a network session with the remote system.
The session begins with whacking, if necessary.
Then it moves through the SYNC procedure into
the exchange of bundles and files.
EXAMPLE:
session
-----------------------------------------------
DOS ... send a command to DOS.
You can process something... or even summon
a stand-alone netmail session-handler.
EXAMPLE:
dos DIR
dos ARCA test *.pkt
-----------------------------------------------
CARRIER ... if there's no carrier when Opus reaches
this keyword, the script will terminate
EXAMPLE:
carrier
-----------------------------------------------
INIT ... go through the normal modem initialization
routine.
-----------------------------------------------
BAUD ... set the computer's async port to the remote
system's baud rate
-----------------------------------------------
CHECKLIST
---------
* Script file names are in quotes in the node list
phone field.
* All script files must be in the NET_INFO sub-directory.
* Each line must have a keyword in the far lefthand column.
* Most keywords require additional information. This
information should be separated from the keyword by a
single space character.
* Most script files should end with "session"
SAMPLE SCRIPT
-------------
This script, for PC PURSUIT, was done by Rick Huebner:
dos if exist outbound\007C00D2.$$? del outbound\007C00D2.$$?
init
baud
xmit ~AT|~ATS0=0|~ATDT3417733|~~~~~~~~~~~~~~~~~~~~
carrier
xmit |~D~|
wait =
xmit ~D1|
wait @
xmit ~c dial214/12,username|
wait =
xmit ~password|
wait T
xmit ~~|~~I|~~ATZ|
wait K
xmit ~ATDT3809063|
wait -
xmit ~~~~~~
carrier
session
------------------------------------------------------------------------------
SAMPLE MATRIX-ORIENTED BATCH FILE
---------------------------------
+----------------------------------------------------------------------+
| |
| Alright - all together now..Ctrl Alt Del,Ctrl Alt Del,Ctrl Alt Del. |
| |
+----------------------------------------------------------------------+
Any batch file for Opus must be able to respond to the
following pre-defined ErrorLevels:
VALUE | MEANING | ACTION
-------+-------------------------------------+---------
255 | an internal error generated by | recycle
| MicroSoft "C". (eg STACK OVERFLOW) |
| |
5 | reserved by Opus | recycle
| |
4 | reserved by Opus | recycle
| |
3 | very very serious error (No FOSSIL, | halt
| no user file, etc) |
| |
2 | minor error (i/o error) | recycle
| |
1 | ^C (keyboard halt request) | halt
| |
0 | ??? | recycle
-------+-------------------------------------+---------
Here is a sample batch file:
+----+----------------------------------------------------+
|Line| Batch file |
+----+----------------------------------------------------+
| | |
| 1 | :start |
| 2 | E: |
| 3 | cd E:\opus |
| 4 | Opus %1 %2 %3 %4 %5 %6 |
| 5 | if ERRORLEVEL 255 goto start |
| 6 | if ERRORLEVEL 8 goto start |
| 7 | if ERRORLEVEL 7 goto bundles |
| 8 | if ERRORLEVEL 6 goto prepecho |
| 9 | if ERRORLEVEL 3 goto end |
| 10 | if ERRORLEVEL 2 goto start |
| 11 | if ERRORLEVEL 1 goto end |
| 12 | if ERRORLEVEL 0 goto start |
| 13 | :prepecho |
| 14 | E:\Opus\Util\ScanMail -maxmsgs 500 -short |
| 15 | :bundles |
| 16 | E:\Opus\oMMM -hE:\Opus\Outbound -cE:\Opus\oBUN.Ctl |
| 17 | goto start |
| 18 | :end |
| 19 | |
| | |
+----+----------------------------------------------------+
NOTES:
Line 5...The check for #255 isn't really needed here
because the following line (ErrorLevel 8) will
end up trapping 255. It's put here to stress
that 255 is a possible ErrorLevel.
Line 6...Checking for ErrorLevel 8 is a safety measure.
It will trap any ErrorLevels above 8, too. In
other words, the batch file is saying "If you
get anything else just recycle."
Line 7...Respond to "Matrix After Edit Exit 7". The
ErrorLevel 7 means something in my netmail message
area has changed. The only thing we need to do
is put the new messages into bundles by calling
oMMM. This ErrorLevel happens after somebody
types a message in the netmail area.
Line 8...ErrorLevel 6 is this: "Matrix After Arcmail Exit 6".
It means we've gotten echomail that needs to be
scanned then put into bundles.
Line 13..PREPECHO calls ScanMail. Note that this falls
through to the bundler.
Line 19..With DOS, you always have to have a blank line
when the last item is a label.
------------------------------------------------------------------------------
TECHNICAL STUFF
------------------------------------------------------------------------------
THE SESSION
-----------
After a connection is established, there's some special
handshaking. The purpose of the preliminaries is to
let Opus determine whether or not it's dealing with another
Opus (or compatible)... and what that other system can do.
Opus is able to detect (or sniff out) another Opus system
using the preliminaries. Once it does that, it knows it's
safe to drop into a more efficient netmail session than
the one currently in use by other<tm> systems.
At the beginning of a netmail session, Opus transmits a
character called YOOHOO<tm>. If the other system understands
the meaning, it will respond. If not, Opus transmits the
TSYNC character understood by other<tm> netmail programs.
If the receiving system acts interested in the YOOHOO<tm>,
the caller sends a full packet of information. It contains
such things as the calling system's name and net/node.
There's even space to add a password later.
Also in the packet is a list of capabilities. Such things
as "I can do YMODEM and ZMODEM" are in this part of the
packet. This is the way the two systems agree on a file
transfer protocol.
If the receiving system gets the packet with no transmission
errors, and if it understands everything in the packet, it
sends back two things:
* An acknowledgement of the packet
* The beginning of YOOHOO/2U2<tm>
The YOOHOO/2U2<tm> is just a YOOHOO<tm> going the opposite
direction: from the receiver to the caller.
At the end of the preliminaries, both systems know precisely
who they are talking to... and the capabilities of the other
side. Using a preset formula, they can agree on a file
transfer protocol.
The YOOHOO<tm> method has plenty of room to grow... to add
additional capabilities. For example, in the works are some
methods for real-time bundling which will do away with the
need to scan and toss echomail.
The method does not cause ill effects on any other<tm>
netmail system currently in operation. If anything, the
other<tm> system will simply think there was one byte of
debris on the phone line in front of the traditional
TSYNC character. Unless the other end responds to the
YOOHOO<tm> character, no other data is transmitted.
Although YOOHOO and YOOHOO/2U2 are trademarked and the
handshake itself is copyrighted, this is NOT a proprietary
method. Specifications are available on request.
FILES IN THE OUTBOUND AREA
--------------------------
- "OUT" files
An "OUT" file is a regular IFNA-type message bundle.
The file name is the remote system's net/node expressed
as an 8-digit hex number. The file extension is ".OUT".
For example, a bundle destined for 124/108 would be
in a file called "007C006C.OUT".
If present, the OUT file is sent using XModem/Crc.
- Files listed in a "FLO" file
A "FLO" file is normally used to contain a list of
files declared as "File-Attach" in messages in the
"OUT" file. In other words, if you create a
"File-Attach" message, the message itself will be put
into the "OUT" file, and the name of the file(s) to be
sent will be put into the "FLO" file.
The file name is the remote system's net/node expressed
as an 8-digit hex number. The file extension is ".FLO".
For example, a bundle destined for 124/108 would be
in a file called "007C006C.FLO".
If present, the FLO file is sent using the VBTS protocol.
That stands for Voodoo-Bondage TeLink/Sealink. First,
there is a MODEM7 file name. That is followed by a
Sealink (or XModem) file transfer. Normally, this
method is compatible with both Sealink and Telink
receivers.
IMPORTANT: If the first character of the file name
listed in the flow file is "#", then Opus
will truncate the file if it is successfully
transmitted. In other words, if the line
"#12345678.TU1" appears, Opus will send the
file "12345678.TU1" and then make it a
zero-length file if the transmission is
consumated.
Z EVENTS
--------
The following is the specs on the Z event. It's not
useful except to a programmer interested in twiddling
or interpreting the schedule data file...
/*-----------------------------------------------*/
/* */
/* EVENTS */
/* */
/*-----------------------------------------------*/
#define EXT_EVENT 'X' /* External event */
#define YELL_EVENT 'Y' /* Yell event */
#define SCHEDS 35 /* Max. # of events */
struct _time
begin
word year; /* Unused */
word month; /* 0..12 */
word day; /* 0..31 */
word daywk; /* 0..7 */
word hour; /* 0..23 */
word mins; /* 0..59 */
word sec; /* Unused */
end;
/*-----------------------------------------------*/
/* Schedule file record */
/*-----------------------------------------------*/
struct _sched
begin
struct _time time; /* Starting time */
word len; /* Duration of event */
int enable; /* 1==Enabled */
word trigger; /* Unknown/unused */
word result; /* X errorlevel */
byte tag; /* Event type */
byte junk_1; /* */
word a; /* OPUS: Reserved */
word b; /* OPUS: Reserved */
word c; /* OPUS: Reserved */
word matrix_mask; /* Matrix ability */
byte junk_2; /* OPUS: Reserved */
byte GMT; /* OPUS: Set=GMT */
end;
The `matrix_mask' field is valid only if `tag'
is Z and `result' is 1. It is subject to contain
debris or be otherwise defined in other cases.
The chief cause of problems is solutions.
-- Eric Sevareid --
###
